In modern data processing environments, a client's data is often distributed among a plurality of heterogeneous database systems (more precisely, a client's data is distributed among a plurality of database instances which were instantiated from different database management systems). "Heterogeneous database systems" are database systems that have different data definition and manipulation procedures, security procedures, system management approaches, capabilities, etc. Examples of "heterogeneous database systems" include DB2 produced by International Business Machines (IBM) Corporation, Oracle produced by Oracle Corp., Sybase produced by Sybase Inc., etc. Such heterogeneous database systems, when used together, collectively represent a heterogeneous, distributed database environment (or system). Heterogeneous, distributed database systems are also sometimes called federated database systems and/or multi-database systems.
In order to enhance user-friendliness, it is preferred that clients be provided with a common interface to all of the heterogeneous database systems (heterogeneous database systems to which a client is not directly connected are called back-end database systems, or simply back-ends). In other words, it is preferred that clients be under the illusion that they are interacting with a single database system.
One conventional. approach for achieving this goal is to introduce an interface module between the clients and the back-end database systems. This interface module, also called database middleware or data access middleware, attempts to provide to clients transparent access to the back-end database systems. Generally speaking, the interface module receives data definition and manipulation instructions from clients. The interface module translates these instructions such that they are understandable to the appropriate back-end database systems, and then transfers the translated instructions to the appropriate back-end database systems. Similarly, the interface module translates information and messages received from the back-end database systems such that they are understandable to the appropriate clients, and then transfers the translated information and messages to the appropriate clients.
Generally, back-end database systems support different sets of functions. For example, some back-end database systems (such as DB2) support the declaration of cursors "with hold". Other back-end database systems (such as current versions of Oracle and Sybase) do not support this function.
Some conventional interface modules address this functional dissimilarity problem by relying on a "least-common denominator" approach wherein the only functions that are supported are those functions that are supported by all of the back-ends. This is not an optimal approach, however, because it does not allow clients to take advantage of all of the functions offered by all of the back-ends.
Other conventional interface modules address the functional dissimilarity problem by disallowing the use of functions when operating with back-ends that do not support the functions. Such functions are allowed when operating with back-ends that do support the functions. This is not an optimal approach, however, since it violates location transparency. That is, clients must be aware of which back-ends they are interacting with.
Thus, what is needed is an improved system and method for addressing the functional dissimilarity problem in a heterogeneous, distributed database environment.